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1. Introduction 


This memo defines how the 6bone uses the 3FFE::/16 IPv6 address 
prefix, allocated in RFC 2471 [6BONE-TLA], to create pseudo Top-Level 
Aggregation Identifiers (pTLA) and pseudo Next-Level Aggregation 
Identifiers (pNLA). 
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The guiding specifications for IPv6 addressing relating to the 6bone 
prefix, and the pTLA and pNLA formats, are "IP Version 6 Addressing 

Architecture" [ADDRARCH], and "An IPv6 Aggregatable Global Unicast 

Address Format" [AGGR]. 


The purpose of creating pseudo TLA and NLA formats for the 6bone is 
to provide a prototype of the actual TLA and NLA formats as they 
might be used in production IPv6 networks. To do this economically, 
using only a minimum of real production IPv6 address space, a single 
TLA, 3FFE::/16, was reserved by the IANA (Internet Assigned Numbers 
Authority) for testing on the 6bone. Thus it was necessary to define 
a pretend-to-be, or pseudo, TLA and NLA structure to use under the 
3FFE::/16 prefix. 


Given the 48-bit length of the IPv6 Aggregatable Global Unicast 
Address external routing prefix (that contains the TLA and NLA 
identifiers), there is enough room to extend the TLA ID to contain a 
pILA and shorten the NLA ID to become a pNLA. This document specifies 
this. 


In early 1999, it was decided to change the 6bone’s pTLA format to 
allow greater expansion of the testbed network, thus accommodating 
more than the original 256 pTLA-s. Thus there are now two 6bone pTLA 
and pNLA formats. This document specifies this. 


2. 6BONE pTLA and pNLA Formats 
2.1 Original 8-bit pTLA and 24-bit pNLA Format 


The original pTLA and pNLA format was intended to accommodate 256 
pILA-s, i.e., backbone networks carrying IPv6 transit traffic. 


The original TLA and NLA ID-s as specified in [AGGR] are as follows: 


The TLA value 1FFE was assigned to the 6bone, which when viewed with 
the 3-bit format prefix in prefix notation form is 3FFE::/16. 


The first 8-bits of the NLA ID space are assigned as the pTLA that 
defines the top level of aggregation (backbone) for the 6bone. This 
provides for 256 6bone backbone networks, or pTLA-s, and leaves a 
24-bit pNLA ID for each pTLA to assign as needed. 
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In prefix notation form the pTLA is 3FFE:nn00::/24, where nn is the 
pTLA assignment. 


The remaining NLA ID space can be used by each pTLA for their 
downward aggregated delegation: 


| n | 24-n bits | 16 | 64 bits | 
4+----- 4+-------------------- 4+-------- 4----------------- + 
| pNLA1 | Site | SLA ID | Interface ID | 
4+----- 4-------------------- 4+-------- 4----------------- + 
| m | 24-n-m | 16 | 64 bits | 
4+----- 4-------------- 4+-------- 4+----------------- + 
| pNLA2 | Site | SLA ID | Interface ID | 
4+----- 4+-------------- 4+-------- 4+----------------- + 

| o |24-n-m-o | 16 | 64 bits 
+----- 4+-------- 4+-------- 4+----------------- + 
|pNLA3| Site | SLA ID | Interface ID | 
+----- 4+-------- 4+-------- 4+----------------- + 


The pNLA delegation works in the same manner as specified in [AGGR]. 
pILA’s are required to assume registry duties for the pNLA’s below 
them, pNLA1’s for those below them, etc. 


2.2 New 12-bit pTLA and 20-bit pNLA Format 


After it became clear that the 6bone would become a useful testbed 
for transition, in addition to its early role as a testbed for 
specifications and implementations, the 6bone community decided to 
expand the size of the pTLA ID. 


Several important decisions regarding this expansion of the pTLA 
field are: 


1. to leave the currently allocated 8-bit pTLA-s in use until the 
space was needed, thus relying on a range value check to indicate 


the new pTLA format, 


2. to use a modulo 4-bit sized pTLA ID to make reverse path entry 
into the DNS easier, 
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3. given 2. above, to keep the pTLA ID size as small as possible 
to not restrict pNLA ID size. 


Therefore, the first 12-bits of the NLA ID space are assigned as the 
pILA that defines the top level of aggegation (backbone) for the 
6bone. This would eventually provide for 4096 6bone backbone 
networks, or pTLA-s, and leaves a 20-bit pNLA ID for each pTLA to 
assign as needed. 


In prefix notation form the pTLA is 3FFE:nnn0::/28, where nnn is the 
pILA assignment. However, as the existing 8-bit pTLA’s are being left 
in use for the present, the nnn value starts at 0x800 for now, thus 
yielding only 2048 pTLA’s in this new format. 


The remaining NLA ID space can be used by each pTLA for their 
downward aggregated delegation: 


|n | 20-n bits | 16 | 64 bits | 
4+----- 4-------------------- 4+-------- 4----------------- + 
| pNLA1 | Site | SLA ID | Interface ID | 
4+----- 4-------------------- +-------- 4+----------------- + 
| m | 20-n-m li? her. ‘|| 64 bits | 
4+----- 4+-------------- 4+-------- 4+----------------- + 

| pNLA2 | Site | SLA ID | Interface ID | 
4+----- 4+-------------- 4+-------- 4+----------------- + 

| o |20-n-m-o| 16. | 64 bits | 

4+----- 4+-------- 4+-------- 4+----------------- + 

|pNLA3| Site | SLA ID | Interface ID | 

4+----- 4+-------- 4+-------- 4+----------------- + 


As with the original pTLA format, the pNLA delegation works in the 
same manner as specified in [AGGR]. pTLA’s are required to assume 

registry duties for the pNLA’s below them, pNLA1’s for those below 
them, etc. 


2.3 Example Format For pNLA’s 
An example usage of the pNLA space is given to demonstrate what is 
reasonable and possible. It should not be assumed that this implies 


the pNLA space must be used this way. As the new pTLA and pNLA format 
is now the default, the example here assumes the 20-bit pNLA format. 
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The following example provides for up to 255 intermediate transit 
ISP's (called pNLA1 below). The pNLA1 value of zero is meant to 
indicate that there is no intermediate transit ISP between the 
backbone pTLA network and the end user site. 


| <----- 20-bit pNLA ID----- > | 

| | 

| 8 | 12 bits | 16 | 64 bits | 
4+----- 4+-------------------- 4+-------- 4+----------------- + 
| pNLA1 | Site ID | SLA ID | Interface ID 
4+----- 4-------------------- 4+-------- 4+----------------- + 


Intermediate transit networks (pNLA1’s) would assign uniques Site 
ID’s for eachend user site served. 


As an example of this, assuming a backbone pTLA of 0x800, no 
intermediate transit ISP (thus a pNLA1 of 0x00) and a sequential site 
ID (with start at the right edge numbering) of 0x0001, the routing 
prefix for the first site would look like: 


3FFE:8000:0001/48 
6bone _|| || ii ene 


Another example of this usage, assuming the same backbone pTLA1 of 
0x800 and an intermediate transit ISP under it (numbering from the 
left edge) with an NLA1 of 0x80, and a sequential site ID of 0x0001, 
the routing prefix for the first site connected would look like: 


b/b site I | |] 
| 
| 


transit 


3FFE:0180:0001/48 
6bone _|| || nik || | site 

HT | 
| 
|| 


b/b site. 
transit_ ~- 


Note 1: the two sites numbered 0x001 in the above examples are really 
two different sites as their pNLA1 authority above them is different 
(i.e., in the first case no transit exists thus the site is directly 
connected to the pTLA backbone ISP, and in the second case the site 
is directly connected to intermediate transit ISP 0x80). 


Note 2: there would be nothing to prevent an pNLA1 transit site from 


further allocating pNLA’s below, but that becomes the policy of the 
pILA and pNLA’s above them to work out. 
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Note 3: The 6bone registry, which is a RIPE-style database for 
documenting IPv6é sites connected to the 6bone, has an "ineté6num" 
object to allow documentation of all IPv6 addresses allocated. 


3. Security Considerations 


IPv6 addressing documents do not have any direct impact on Internet 
infrastructure security. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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